Size Change: +67 B (0%)

Total Size: 1.23 MB

_{compressed-size-action}

As much as I want negative margin support. I do think we need to consider how a block with a negative margin will interact with those around it in the Editor. It may become extremely difficult to edit, and there are also z-index issues.

Thank you for tackling negative margins @JustinyAhin 👍

Ultimately, I'd love to see negative margins supported and the designs they can unlock realised.

At this stage though, I think we might have merged these changes a little prematurely. I agree with @ndiego that allowing negative margins as they are, introduces more potential problems than they solve.

There are also a few other minor issues I think needed to have been addressed before merging this PR.

With limited testing and explorations so far some of the issues I see include:

• Interactions within the editor are clunky once blocks begin to overlap. e.g. z-index and block selection problems.
• Any change to the components within wordpress/components should have a changelog entry
• Any new props should be documented in the readme (unless __experimental)
• As raised elsewhere we could have avoided the new prop entirely which also avoids having to support it in the future
• Allowing negative values within the BoxControl required further updates to how "mixed" values are determined so a single negative margin value is still displayed via the BoxControl's linked state.
• Could the margin block support's visualizer have been extended in a way to reflect negative values (I'm not saying it's easily achievable but rather something we might look at).

Some of the above are obviously trivial and can still be done after the fact. The editor problems though need further exploration. Are we happy with leaving the potentially broken UX in the editor in order to keep negative margins?

I'd like to stress supporting negative margins would be great and I personally appreciate the effort put into this but I don't think we should be regressing the editor's UX to achieve it without due consideration.

I opened #40674 to revert this PR if that's what we want to do 👍

I kindly disagree that this would introduce more problems than it solves. Currently theme and plugin authors have to implement their own solutions because there is no standardized way. This creates more problems in the long run.

@aaronrobertshaw in the screen recording, isn’t that the expected behavior? If I was to enter a negative value, I would expect it to work exactly like that.

There’s many worse things that users can do to break the page layout very easily. For example align full and align wide. Or the navigation block. It can take users hours to reorganise their block structure, whereas fixing the above issue is a simple matter of removing the negative value from the input.

Another thing worth noting is that sometimes negative margins just don’t work. This is not a block editor issue, but CSS in general. At least allowing negative values would work most of the time.

Is there anything that can be done to help solve this problem? I know that it’s a deal breaker for many designers.

Thanks @seothemes for taking the time to share your thoughts 👍

In the screen recording, isn’t that the expected behavior? If I was to enter a negative value, I would expect it to work exactly like that.

The recording also demonstrates that single negative margin values aren't displayed as such in the margin box-control which is not expected behaviour.

Whether the overall behaviour shown in terms of block selection was expected or not might be a separate question from whether that behaviour is desirable at the moment.

Some initial questions that come to mind around it might be:

• How will negative margins impact or be constrained by layout block supports and styles?
• How many users are aware of, and frequently use, the list view for block navigation vs keyboard vs mouse selection etc?
• What UX impacts are there for users on smaller screens or mobile?
• Should negative margins be something that an average user control or would limiting it to themes limit the potential conflicts as those negative values would be applied in a deliberate manner?
• Can we have something like the parent block button where if there are multiple blocks under the cursor they are shown in the block toolbar for easy selection?
• If blocks are to overlap, should we also be offering control over z-index as well?
• What effects would custom z-index values have on other editor features like toolbars, padding/margin visualizers etc?
• Could we limit negative margins to a sane value that prevents a lot of the block navigation/UX issues?

I'm sure there'll be a lot of other aspects to consider as we explore how best to add support for negative margins.

There’s many worse things that users can do to break the page layout very easily

Personally, this gives me further pause towards adding another way to break layouts.

Another thing worth noting is that sometimes negative margins just don’t work. This is not a block editor issue, but CSS in general. At least allowing negative values would work most of the time.

This is a good point.

My understanding of the general approach in Gutenberg is to try and avoid situations where users are setting values and nothing changes. There are already issues with this in regards to left/right margins depending on the context a block finds itself in. I don't know whether that makes it better or worse with regards to adding negative margins.

Is there anything that can be done to help solve this problem? I know that it’s a deal breaker for many designers.

There's definitely a demand for negative margin support. I expressed my desire to see it in my earlier comment also.

In terms of moving this issue forwards, I think we need to address concerns around how negative margins affect interactions in the editor.

Perhaps our best bet is a threaded discussion, to outline what the UX issues are, gather ideas to mitigate them and form a consensus view on where best to place our efforts in generating some proof of concept PRs exploring our ideas.

What a great reply, thank you for describing the challenges so well.

I missed the single values part in the screen recording, but that's the important bit. Makes me wonder - should negative values only be allowed on individual sides? What would be the use case of having negative margins on all sides at once?

Limiting negative margins to individual sides would help prevent users from breaking layouts.

If blocks are to overlap, should we also be offering control over z-index as well?

I don't think z-index is necessary, and would likely overcomplicate things. We don't need to allow for every possible layout, just the basics. I feel like z-index is closer to positioning, and can quickly get out of control.

We have z-index controls in Blockify for example, which feels like overkill:

Personally, this gives me further pause towards adding another way to break layouts.

Haha, very good point, and that's the right perspective to have.

would limiting it to themes limit the potential conflicts

Yes, and this would still solve the problem. Themes and plugins should be allowed to do this, whether or not it's added to core. It's just very hard to change and extend from the outside because it's hardcoded.

If added to core, maybe require theme support in theme.json spacing settings to begin with? This would give time to refine and improve the UI:

{
  "settings": {
    "spacing": {
      "negativeMargin": true
    }
  }
}

The new spacing scale does allow for negative values, but that's also applied to padding, which means it's not an option 😢 (#32644 (comment))

My understanding of the general approach in Gutenberg is to try and avoid situations where users are setting values and nothing changes

I'm not sure how other page builders handle situations where the value has no effect, this goes back to negative margins being a CSS issue, which can't really be solved.

Here's how it's done in Webflow for reference:

I guess this topic is bigger than just negative margins. Is the direction of WordPress heading towards no-code, or will it always be "half-code", with the gaps filled by themes and plugins? There seems to be no clear roadmap or intention, unless I'm missing something.

should negative values only be allowed on individual sides?

It may turn out that this would be desired. If negative margins were only allowed for individual sides, we'd need some UI updates regardless. For example, how do we communicate there are different min/max constraints when the control is link/unlinked? How do we avoid confusion and frustration if the user does try to apply a negative margin to all sides?

What would be the use case of having negative margins on all sides at once?

I'm not sure, however, if we are to solve the issues with negative margins for individual sides, I'd guess we'd be in a reasonable place to allow it for all sides.

Themes and plugins should be allowed to do this, whether or not it's added to core

It might be worth noting that negative values are allowed within theme.json. This, of course, only helps when styling all of a given block type. If we are needing to allow configuration of margins for individual blocks via the editor, then I'm not sure we can limit it to theme authors after all. This would bring us back to a theme supplying a custom class and CSS to satisfy their specific needs.

	...
	"styles": {
		"blocks": {
			"core/group": {
				"spacing": {
					"margin": {
						"top": "-100px"
					}
				}
			}
		}
	}

I guess this topic is bigger than just negative margins.

It is in some ways and why I believe it was wise to revert this PR and take a moment to work through the issues before we end up having to provide ongoing support to a potentially broken feature.

In the lead-up to the 6.1 release, I don't have the bandwidth at the moment to wrangle such a complex topic but if you wish to get some further traction on this, I'd recommend creating a new discussion so broader input and feedback can happen.

There seems to be no clear roadmap or intention, unless I'm missing something.

There are a number of resources available detailing a roadmap for Gutenberg and WordPress. Whether that is from a long-term view or for the next release. Here are a few you might find interesting:

• Overall WordPress/Gutenberg Roadmap
• Roadmap to 6.1
• Gutenberg: Phase 2 - Customization
• Global Styles Ongoing Roadmap

Thanks again for the very helpful info. Definitely feeling ya on the bandwidth, it's a lot. Appreciate the energy you've already put in.

I spent some time on this and came up with a workaround to allow negative margins:

It's not perfect, negative values need to be entered manually, but that's good in a way. The option is there for designers/developers, but also hidden for beginners. However after doing some testing, I found that negative margins aren't that helpful when it comes to the block editor. Without responsive controls, there's not much that they can be used for.

I'm not sure negative margins are the answer. A much better solution would be for core to add a CSS grid block with responsive settings. That would remove the need for negative margins and many other things. Here's a great example https://wordpress.org/plugins/grids/

Below is the code that I'm using for testing negative margins if anyone is interested:

import { createHigherOrderComponent } from '@wordpress/compose';
import { addFilter } from '@wordpress/hooks';

addFilter(
	'editor.BlockEdit',
	'blockify/with-negative-margin',
	createHigherOrderComponent( BlockEdit => {
		return ( props: blockProps ) => {
			if ( supportsNegativeMargin( props?.name ) ) {
				const input = document.querySelector( '.components-input-control__input[min="0"]' );

				if ( input ) {
					input.setAttribute( 'min', '-999' );
				}
			}

			return <BlockEdit { ...props } />;
		};
	}, 'withMinHeightSettings' )
);

Thanks again for the very helpful info. Definitely feeling ya on the bandwidth, it's a lot. Appreciate the energy you've already put in.

looks different. not the default gutenberg editor shipped with wp 6.0.2 ?!

@nicmare not sure which version this was on but it still works with 6.1

@nicmare not sure which version this was on but it still works with 6.1

meanwhile with latest wp i have the new interface and can insert negative values which are reflecting in the editor. But when i hit enter or push save button, it gets reset to zero again :-(